One thing I've realized is the following.

from enum import Enum


class IntEnum(Enum):
    A = 1
    B = 2

IntEnum.A == 1  # False

Which means that when the LLM calls a function which accepts a type of IntEnum, it will fail because IntEnum.A is not the same as 1, for example.

To me there are two possible options:

1. We could warn the user in the documentation that they need to deal with this. Not ideal but the fix would just be to add IntEnum(1).
2. We could wrap the provided function to do the conversion ourselves. This would obviously be more convenient, but wonder if that introduces other problems.

What do you think @lorenzocelli

Right. I agree with you, the first option is not ideal.

I think we could implement the second more easily if we stored the list of ParameterSchema objects in FunctionSchema. Then we could do something like the following inside _GPTEnabled.__call__ (ignoring args here):

def __call__(self, *args, **kwargs):

    p_schemas: list[ParameterSchema] = self.schema.parameters

    for schema in p_schemas:
        if isinstance(schema, ListParameterSchema):
            # replace value with corresponding enum type
            kwargs[schema.parameter.name] = IntEnum(kwargs[schema.parameter.name])

    return self.func(*args, **kwargs)

We could also delegate to ParameterSchema the task of converting a value back and remove the call to isinstance.

Yeah I think that sounds good!

We're still missing the value to enum conversion on invocation

@lorenzocelli I've marked this as a draft. Let me know when it's ready for me to review 👍

@siliconlad when we convert the enum to a set of values to send to the api, do you think we should keep the values or the names? Names are usually more informative than values, such as in this example from the python docs:

class Color(Enum):
    RED = 1
    GREEN = 2
    BLUE = 3

In order to store the parameter schemas inside the function schema, I found it convenient to remove the static methods in favour of a more instance-oriented approach. For example FunctionSchema.schema(...) -> dict becomes mySchema._populate_schema(...) called in the constructor to populate the schema dictionary. In this way it is easier to store other information like parameter_schemas in the process.

Another way could be to keep the static methods and provide them with a parameter_schemas dictionary to fill.

@siliconlad when we convert the enum to a set of values to send to the api, do you think we should keep the values or the names? Names are usually more informative than values, such as in this example from the python docs:

class Color(Enum):
    RED = 1
    GREEN = 2
    BLUE = 3

The LLM might perform better with the names I think.

The LLM might perform better with the names I think.

I suspected, I will mark this as a draft again then

Refactored ParameterSchema implementation to be closer to FunctionSchema implementation (using get_...() methods)

To support Enum parameters with default values, I added a ParameterSchema.encode_value method to convert an instance to its json representation (in the case of Enum, the name). Contextually I renamed parse_value (which converts the json representation to an instance) to decode_value.

I updated the 'enumerations' section of the README